Replacement cycling attacks

M1 --> Alice --> M2

Alice が被害者

M1 と M2 が攻撃者

M1 から Alice を中継して M2 に送金している場合を想定

Alice ---> M2 は完了して M2 が受け取ったのに、M1 --> Alice は timeout して M1 が BTC を取り戻すことで、Alice から BTC を盗むというのが基本的な構成

Pinning attacks もこの構成は同じはず

M1 --> Alice が timeout して M1 が BTC を受け取るまで、Alice --> M2 において success も timeout もさせないようにする

このような事態が起きないように、M1 --> Alice の HTLC timeout 時間は Alice --> M2 のそれよりも長くすることになっている

M1 --> Alice の HTLC timeout 時間が Alice --> M2 のそれと近ければ近いほど、M2 が timeout ぎりぎりで preimage を使って HTLC を回収した時に、Alice が preimage を使って incoming HTLC を回収するまでの時間的余裕が小さくなる。

Alice が timeout tx で Alice --> M1の HTLC を回収しようしたら、攻撃者は success-tx で Alice の timeout tx をリプレイスする

success-tx が confirm すると Alice に preimage が知られてしまうので工夫が必要

Alice は preimage が手に入れば送金を完了することができるので、攻撃はその時点で失敗になる

success tx は commitment tx だけではなく、攻撃者が作成する unconfirmed tx Aを input にしておく

success tx が timeout tx をリプレイスしたあとに、success tx の input であった tx A をリプレイスすることで success tx 自体を無効にし、mempool から消しさる

timeout tx をブロードキャストされるたびに、これらの replace を繰り返す

この絵がとてもわかりやすい

詳細はメーリングリストで報告されている

Both for legacy and anchor output channels, a HTLC-preimage on a counterparty commitment transaction is malleable, i.e additional inputs or outputs can be added. The HTLC-preimage spends anunconfirmed and unrelated to the channel parent transaction M and conflictsits child.

In an ulterior move, the malicious counterparty can replace the parenttransaction itself with another candidate N satisfying the replacementrules, triggering the eviction of the malicious HTLC-preimage from themempool as it was a child of the parent T.

攻撃者の success tx は、commitment tx 以外の unconfirmed tx を input にしておく。timeout tx がリプレイスされたあとにこの tx をリプレイスすることで、timeout tx をリプレイスするためにブロードキャストした success tx も不正なものとなり mempool から削除される。このとき commitment tx を unlock しようとする tx はない状態。

Once this chain of transactions is well-propagated on the transaction-relay network, Mallet replaces the parent of the chain A with a higher-fee / high- feerate transaction. There should not be anymore a pending spend of the offered HTLC output in a network mempools.

success tx に commitment tx 以外の input A を持たせておき、その input tx Aをさらにリプレイスすることで、success tx を不正な tx にして mempool から除外する

RBF の2つ目の条件として、replace する tx が unconfirmed な tx を input にする場合、その tx は replace される tx の input に含まれているものでなければならない、と定められている

この条件があるため、tx A を input に持つような success tx が timeout tx をリプレイスするためには、timeout tx が tx A にしているか、すでに tx A を input にしている別の tx をリプレイスしなければならない

当然 timeout tx は tx A を input にはしていない

そのため、事前に tx A と tx A を input にする tx B を confirm させない状態で mempool に入れておく

これにより、success tx は timeout tx と tx B をリプレイスする形で、条件をクリアする

If the HTLC-preimage propagates inside the local mem- pool of the victim node, opportunity is given to extract the preimage from the HTLC transaction and construct a satisfying witness to claim the offered output on the inbound channel state.

被害者は preimage を知ることができれば ok

攻撃者は被害者の mempool に preimage を含む tx が入らないように工夫することが考えられる

pinning attacks も同じアプローチ

このペーパーにはその方法の一例が示されている

参考になりそう

完全に防ぐことはできない

考えられる緩和策

victime が preimage を知ることができれば ok なので、LN node は local mempool を監視し、success tx を検知する

LN node がマイナーの mempool を直接観測する

これは pinnig attacks への対応として以前提案されている

timeout tx のブロードキャストを繰り返す

攻撃者となりうるノードと channel を開かない

LND は v0.16.1 で緩和策をリリース

解決するには bitcoin レベルでの対応が必要

一度 mempool に入った tx を後から確認できるしくみがあれば、preimage を知ることができる

pinning attacks は nVersion3 + new package relay policy で解決できる(?)が、cycling attack はそうはいかない

Pinning attacks は success tx を低い手数料にすることで confirm させないようにするので、mempool が混んでいる必要がある

Pinning attack では mempool の分断が必要

cycling には必ずしもこの条件は必要ではない

mempool の分断ができると、攻撃者にはより有利になる

Peter todd

参考までに LN/Bitcoin 主要開発者がどのように考えているか

Matt Corallo

Now, the above is all true in a spherical cow kinda world, and the P2P network has plenty of slow nodes and strange behavior. Its possible that these mitigations might, by some stroke of luck, happen to catch such an attack and prevent it, because something took longer than the attacker intended or whatever. But, that's a far cry from any kind of material "fix" for the issue.

LN node が使っている bitcoind がわかりやすい場合、攻撃者に有利

直接被害者の mempool でリプレイスはむずかしいか？preimage がすぐにばれる

マイナーの bitcoind に直接働きかけられる場合も攻撃者に有利

Osuntokun

That's all to say that imo, this is a rather fragile attack, which requires:per-node setup, extremely precise timing and execution, non-confirmingsuperposition of all transactions, and instant propagation across the entirenetwork of the replacement transaction (somehow also being obscured from thePoV of the defender). The attack can be launched directly with a miner, or"into" their mempool, but that weakens the attack as if the miner broadcastsany of the preimage replacement transactions, then the defender can onceagain use that to extract the preimage and settle the incoming HTLC.

Maxim Orlovsky

The latest cycling attack on Lightning seems to me the case of “you can rob the bank if you dig underground tunnel to the vault and use perforator to break through the concrete wall”. True statement, but still impractical for 99% of time.

ACINQ